Serial No. 09/785,385 - 6 - 52101sh 



REMARKS 



Claims 1 and 3-6 stand rejected under 35 USC §102(b) over U.S. Patent No. 6,138,144 to 



o 
o 
o 

CO 

00 
CNJ, 

s 

o 
o 

CO 

z DeSimone. DeSimone resides in a method for managing multicast addresses for transmitting and 

§ receiving multimedia conferencing information on an internet protocol (IP) network implemented over 

s - an ATM network. The architecture allows client selection of which packets to receive based on the 
< 

o originator of the packets. 

| A multicast address resolution system (MARS) is used to identify receivers. The innovation 

o 
o 

LU 

to 

LU 

3 



appears to be a global MARS server that understands how to address each participant in a conference 
session. 

g Broadly, DeSimone is directed to optimizing normal multicast communications over non-IP 

g (ATM) networks by consolidating into a global spot a MARS, Multicast Address Resolution System. 
| 

g This system knows each client network address to which traffic is to be sent - the innovation is to 
Q 

| globalize this rather than put a MARS into each subnet. 
_i 

2 Claim 1 has been amended to set forth that the instant invention includes one or more network 

o 

" routing modules (or router-embedded applets) operative to distribute messages based upon the content 
6 

°\ thereof '(in addition to normal packet routing). This distinguishes over DeSimone is several significant 
I 

g ways: 

o DeSimone identifies destinations by address only - not by message content type (i.e. clients 

o select which streams to accept) - according to the present invention, messages are routed based on logic 

DC 
LU 

g in the FedHost - i.e. the router itself, not based on client logic or preference (although logic exists in the 
< 

m - system to allow for this case); 



£ (1) The routing fabric (i.e. Multicast) forwards all messages by destination address in DeSimone. In 



§ Applicant's system, some or all packets are actually NOT routed based on router logic which is 

or 

OT - keyed by packet content (interpreted by application-specific code or applets included in the 

* router - code that in effect "understands" the meaning of the packet stream and uses that to 

Q 

o affect routing/no routing decisions); 

LL 

^ (2) There is no MRAL (Multicast Receive Address List) in our routers unless implemented in an 
application specific way by applet logic. 
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Thus, Applicant's system allows each client to send packets to all other clients in a network (i.e. 

CO 

m 

g to multicast), but dynamically allows the routing fabric to determine to which clients the traffic should 

o 

CO 

z go (for slowing or disconnecting particular clients), based on packet content itself. Each broadcaster 

< 

o 

i would 'think' it was sending to all clients, and all clients would 'think' that they are getting everything, 

|- but the routing fabric would not route all data sent to all clients receiving based on logic that is internal 
< 

0 to the router and is based on the requirements of the applications generating the traffic (i.e. this logic is 
| inserted into the routers by the application developer), 

1 The advantage of Applicant' s approach over DiSimone is that clients do not need to understand 

LU 

anything about the network optimization. However, to accomplish this the routers must be application 
g specific - i.e. they must know about network optimization. 

g Claims 7-9, 11 and 14-23 stand rejected under 35 USC §103(a) over DeSimone in view of 

g Waters (5,841,980). It is believed that claims 7-9, which depend from claim 1, are allowing based upon 

Q 

> the arguments above under 35 USC § 102(b); that is, even if the DeSimone/Waters combination were 
_i 

2 legitimate, Applicant's invention would not result. 

o 

8 However, the DeSimone/Waters combination is without justification. Concerning claim 1 1, the 

b 

°\ Examiner argues that the DeSimone/Waters combination "makes sense" because it would result in "a 
| more optimal interaction among its multiple users." However, this argument is too nebulous to 
o constitute a sufficient grounds for rejection. The Examiner must provide a reason why one having 

Z 



0 ordinary skill in the pertinent art would have been led to combine the cited references to arrive at 

cc 

1 Applicant's claimed invention. There must be something in the prior art that suggests the proposed 
< 

w combination, other than the hindsight gained from knowledge that the inventor choose to combine these 
s particular things in this particular way. Uniroval Inc. v. Rudkin-Wilev Corp. , 837 F.2d 1044, 1051, 5 

CO 

§ USPQ2d 1434, 1438 (Fed. Cir. 1988). The Examiner is also required to make specific findings on a 
£ suggestion to combine prior-art references. In Re Dembeczak . 175 F.3d 994, 1000-01, 50 USPQ2d 
g 1614, 1617-19 (Fed. Cir. 1999). 

Q 

§ Although the Examiner argues that Waters represents analogous art, this in not really the case. 

LL 

o Whereas Waters is optimized for computer gaming, DeSimone is optimized for multicast multimedia 
(i.e. video conferencing). Indeed, Waters addresses large-scale, multiplayer gaming, and calls for 
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O 
O 
O 
CO 

~ dividing the game space (the virtual play board) into multiple zones, which can be served by a single 

CM 

5 server. This means that as the player moves about the playing field he is logically connect to the server 

CO 

g for the specific zone in which his play is logically occurring. Such an architecture would be of no 

o 

00 

2 benefit to DeSimone which is directed to optimizing normal multicast communications over non-IP 

x (ATM) networks. The point of novelty is knowing each client network address to which traffic is to be 

§ sent, rather than implement a multicast address resolution system each subnet. 
< 

o In Applicant's system there are no fixed zones, and the zones are not associated with a particular 

| simulation or game server. Note the limitation in claim 1 1 of "one or more routing modules or router- 



§ embedded applets that implement application- specific message culling. . As discussed above, this is 

UJ 

& markedly different that the DeSimone system and the proposed addition of Waters does not cure this 

D 

g deficiency. In contrast to the cited references, Applicant's routing fabric has "culling rules" it uses to 

g determine if two players need to interact - these rules are game and game developer specific. They 
| 

g exist identically in every server that routes traffic and applied identically regardless of to which server a 
o 

| game client connects. Logically, all clients exist in the same unzoned game space, but traffic between a 

_i 

° pair of clients is controlled by their relative positions (which is represented as data in the packets that 

o 



" could be sent from one to another - i.e. based on game-specific packet content). 

b 

* Waters describes the old way multiplayer games are implemented on a fixed, or zoned space, 

CO 

I while Applicant's invention implements games and simulations without a fixed zoned space using 
o dynamic rules which can be used to create either fixed or dynamic zones of inclusion (or exclusion), 
o Claims 2, 10, 12 and 13 stand rejected under 35 USC §103(a) over DeSimone in view of Waters 

tr 

| (5,841,980), and further in view of Lambright (6,015,348). Apart from the fact that there is no evidence 
< 

ufrom the prior art that suggests the proposed combination, Lambright, like DeSimone, uses fixed zones. 
E In contrast, Applicant's does not use fixed zones at all. Lambright is a variation on the Waters idea of 

CO 

g fixed zones that client connects to keep traffic to a particular processor below a fixed limit, but includes 

DC 

® the idea that the zones (they call sectors managed by a sector manager) are dynamically created based on 

% 

£ client traffic. 

Q 

o Based upon the foregoing amendments and comments, Applicant believes all claims are in 

LL 

u condition for allowance. Questions regarding this application may be directed to the undersigned 
attorney by telephone, facsimile or electronic mail. 
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Dated: January 21, 2005 



Respectfully submitted 



By: 

John G. 
Reg. Ni 

Gifford Kra^, Groh, Sprinkle, 
Son & Citkowski, PC 
280 N. Old Woodward Ave., Ste 400 
Birmingham, MI 48009 
(734)913-9300 FAX (734) 913-6007 
Email: iposa @ patl aw .com 
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